home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
FishMarket 1.0
/
FishMarket v1.0.iso
/
fishies
/
426-450
/
disk_441
/
dme
/
src
/
test
< prev
next >
Wrap
Text File
|
1992-05-06
|
2KB
|
49 lines
Well, I've now got my entire compiler registerized, with some interesting
results:
OLD NEW CHANGE
DICE/compile-DME (time) 2:38 2:33 3.2% faster
DICE/sum_executable_sizes 235K 224K 11K (5%) smaller
DME/executable_sizes 67K 56K 11K (15%) smaller
c.lib(unreg) cr.lib(reg) 52172 51244 928 bytes smaller
I was somewhat surprised by these numbers, only DME's make complete sense.
I expected *MUCH* smaller DICE executables but it didn't materialize. I
was hoping for a better improvement in speed but since none of the
core algorithms I use are call-intensive the 3.2% does make sense.
DME, on the other hand, is extremely call intensive, thus the much greater
benefit from registerized parameters.
BTW, on the c.lib/cr.lib sizes, I noticed that Lattice's LC.LIB vs
LCR.LIB had a 1348 byte difference in size (i.e. about the same as I
got with DICE).
I would conclude the following things from this:
(1) registerized parameters do not make procedure definitions any
smaller
(2) registerized parameters DO make procedure-CALLS smaller, but only
by virtue of getting rid of the stack pop. Code -> reg vs
Code -> stk takes about the same amount of space.
(3) registerized parameters make procedure call overhead MUCH faster,
but you only notice the benefit if you program is call-intensive
at the core level.
All in all, I like them. I think that instead of implementing in-line
library calls I will simply write a program to generate a registerized
call interface. Overhead will be nearly the same as for inline, the
tags will be much smaller, and I do not have to deal with all that crazy
pragma stuff. I want the programmer to be able to simply #include the
new 2.0 prototype files to get the regcall interface.
-Matt